Hi @robertcoltheart

Code wise this looks good but its not actually changing the encoding for me.

I created an ANSII.txt and included it in my project then I have the following .editorconfig

[*]
charset = utf-8

With additional logging i can see that everything flows as expected when saving:

File 'Projects\ClassLibrary1\ANSI.txt' should be encoded with: UTF8

but issueing the following command:

$ file -bi ANSI.txt

will return

text/plain; charset=us-ascii

If i save the file outside of visual studio (e.g with notepad) and force the encoding to utf-8 it will return:

text/plain; charset=utf-8

Ok TIL, if visual studio thinks your file is ascii it will always save it as ascii 😄

If i insert a non ascii character these encodings are adhered to.

Will add a note of this in the autcomplete (also fix the autocomplete options)

Yeah its probably not a perfect way of doing things, but I think it follows the "softly softly" approach of EditorConfig to act as a guideline and not as an enforcer.

...it follows the "softly softly" approach of EditorConfig to act as a guideline and not as an enforcer.

Is this entirely correct? If it is, then I believe there is certain inconsistency between different rules.

For example, with trim_trailing_whitespace = true, opening a file containing lines with trailing whitespace, making a random change, and saving results in the trailing whitespace being removed, even if the change did not touch any of the offending lines. To me, this sounds more like enforcing than guiding, and this IMO is a very good thing.

Now, contrasting that to charset = utf-8, I open a file encoded as Unicode (UTF-8 with signature) - (Codepage 65001), make a random change in the middle of the file, and save it. This results in the BOM left alone, and not removed to match other rules' behavior, as one would expect.

@dliuzzi I'm only a contributor to this project, and was merely referencing the FAQ and comments here: #25 (comment). I'm not sure if this is still a goal for EditorConfig, someone with more knowledge than me would need to comment.

@robertcoltheart I see your point now. I was just bringing up consistency as I think it makes things easier to grasp. I.e. having all rules be either one way or the other, but not both, as to not having to remember which ones act as enforcers and which as guides. In my case, I'm in favor of enforcing, but I understand if maintainers think differently. Anyway, I'm one of the people who's been eagerly expecting charset support, so you taking the time and effort to implement it is highly appreciated.